<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <title>Philosophy and Apology</title>
  <link rel="stylesheet" type="text/css" href="mbgstyle.css" />
</head>
<body>
<h1>Philosophy and Apology</h1>
<p>Some philosophical questions might be raised by this tool because the
 tool is more focused on database tables than on the domain model.
 We will take a few paragraphs to talk about this approach.</p>

<p>First of all, this tool does what it does.  We are not making any kind of statement
about how projects should, or should not, be structured.  In general we are strong proponents
of rich domain models - but creating a rich domain model is quite a different thing from
answering the question of how that model should be persisted.</p>

<p>If your particular design philosophy  is that the domain model drives all decisions, and
 that the database design is subservient to the domain model, then this tool - and MyBatis
 itself - may not be the proper fit for your application.  In that case, we would suggest
 taking a serious look at <a target="_blank" href="http://www.hibernate.org">Hibernate</a>
 - it may fit
 more closely with your application design and philosophy.</p>

<p>But not all projects fit that paradigm.  Very few truly enterprise
 class applications do.  MyBatis can be of great help in projects where
 database design is seen as a co-equal to domain object design.
MyBatis is not an object relational mapper, and does not attempt to transparently
persist objects.  So it falls on application developers to write SQL to interact with
database tables.</p>

<p>In large or enterprise class projects, many of these factors are quite common:</p>
<ul>
  <li>Database design is often a separate function (with separate management) from OO domain
      design
  </li>
  <li>Database designers do not have OO tools (like inheritance), so they don't think
      in OO terms</li>
  <li>Application designers do not have complete control over the final form of database tables.
    For example, the data that seems to fit in one object for the application, may be split
    into several tables in the database.</li>
  <li>The database design often ends up quite different from the OO design, leading to
   a significant mismatch between tables and objects.</li>
</ul>
<p>
These factors are primary indicators that MyBatis is a good candidate tool for your
application, and this is the type of project where MyBatis Generator can make a significant impact.
So how should MyBatis be used in this case?</p>

<p>The Data Access Object(DAO) pattern is still a primary pattern.  MyBatis Generator can generate a basic
set of objects that match each individual table.  Generated code is transaction neutral.  This means
that it is easy to extend the generated code to add transaction attributes if more than one table is involved in
a transaction.  Or, you could create another DAO (or service method) that more closely matches the
persistence needs of a domain object
and make use of one or more generated objects in a single transaction.</p>

<p>As an example, consider a typical <code>Order</code> object - the typical header/detail problem.
In some environments such an object would be persisted into at least 4 tables -
two key tables, a "header" table, and a "detail" table (again, we are not making any kind of
statement about whether this is "correct" design, just stating a fact).
Your application should still interact with interact with the <code>Order</code> object, and
there might
be a <code>saveOrder(Order order)</code> method
somewhere (in an OrderDAO, or a service object).  That method
would interact with the generated code for each of the 4 tables involved.</p>

<p>What has code generation bought us in this case?  Several things:</p>
<ul>
  <li>Reuse - it is likely that some tables will need to be accessed from multiple different DAOs
  or service methods.  Creating a DAO for each table promotes reuse and consistency within the
  application.</li>
  <li>Database abstraction - a service layer typically defines persistence in your application.  Those
    methods can be stabilized fairly quickly.  As database design evolves:
    <ol>
      <li>Code can quickly be regenerated as the tables change</li>
      <li>The service methods can be modified as necessary</li>
      <li>Higher layers in the application remain unchanged</li>
    </ol>
  </li>
  <li>Developer productivity - generating table based DAOs is quick and repeatable and error free.
    Developers can concentrate on Object persistence, and on complex join queries if needed.</li>
  <li>Fewer defects - because the most tedious and error prone part of any application (getting the
   SQL to match the objects) is automated.</li>
</ul>
</body>
</html>
